fix(acp): state the reply delivery contract in the turn prompt - #4346

Problem

A managed agent's reply reaches the channel only if the model spontaneously decides to run buzz messages send. The turn prompt told agents to use --reply-to on buzz messages send, but never stated that session text is not delivered — so weaker models answered in plain session text and every reply was silently dropped: the turn ran, tokens were billed, the Activity panel streamed the answer, and the channel stayed empty with nothing logged. Reproduces #2698.

Root cause

The delivery contract is implicit. append_reply_instruction and append_new_thread_reply_instruction (crates/buzz-acp/src/queue.rs) describe --reply-to threading and name buzz messages send as the mechanism, but never state the negative: session text is not delivered. Models that don't infer this convention (the issue reproduces with Sonnet 5 vs Fable 5 on an otherwise identical turn) lose every reply.

Fix

State the contract explicitly at the top of both instructions:

```
Your session text is NOT delivered to the channel —
nothing you type here reaches the human unless you send it.
To reply, run buzz messages send --reply-to {event_id} ...
```

This is the model-agnostic, immediately effective direction the issue author verified locally ("adding the equivalent instruction to the agent's system prompt makes Sonnet 5 post correctly"). The larger harness fallback (auto-posting final session text when no send was observed during the turn) is intentionally not included here — it's a bigger change worth its own PR.

Test

• Updated test_reply_instruction_present_for_channel_thread_reply to assert the delivery contract is stated.
• 648 buzz-acp unit tests pass (one unrelated keepalive_resets_idle_past_deadline fails on this WSL host due to ms-scale timer jitter — it fails identically on unmodified main, not caused by this change).
• cargo fmt --check and cargo clippy clean.

Closes #2698